1. Field Of The Invention
The present invention relates generally to the field of programmable integrated circuits (ICs), and more specifically to a method for generating secure configuration data for programmable ICs.
2. Description of the Background Art
Programmable ICs are typically configured by creating a program file which is then used to program the device. The first step in generating such a program file typically involves defining an electronic circuit using design entry tools to enter a description that is either language-based (e.g., described in Hardware Description Language, or HDL) or schematic-based (built from illustrations of circuit elements or gates). (The term "programmable ICs" as used herein includes, for example, Field Programmable Gate Arrays (FPGAs), mask programmable devices such as Application Specific ICs (ASICs), Programmable Logic Devices (PLDs), and devices in which only a portion of the logic is programmable.) This circuit description is then processed to form a netlist description of the circuit. (A "netlist" is a description of a circuit comprising a list of low-level circuit elements or gates and the connections (nets) between the outputs and inputs thereof.) The resulting netlist is typically compiled using a series of software steps such as: 1) mapping the circuit elements in the netlist into logic blocks available in the programmable IC; 2) placing the mapped logic blocks in specific locations in the programmable IC; and 3) routing the nets between the logic blocks according to the connections specified in the netlist. Mapping (also called partitioning), placing, and routing are described by Bryan T. Preas and Michael J. Lorenzetti on pages 65-210 of "Physical Design Automation of VLSI Systems", published in 1988 by The Benjamin/Cummings Publishing Company, Inc., which are incorporated herein by reference. Mapping and routing are also discussed by Stephen D. Brown et al on pages 45-86 and pages 117-145, respectively, of "Field-Programmable Gate Arrays", published 1992 by Kluwer Academic Publishers and incorporated herein by reference. Placement is discussed extensively by K. Shahookar and P. Mazumder of the Dept. Of Electrical Engineering and Computer Science, University of Michigan, in "VLSI Cell Placement Techniques", published June 1991 in pages 143-220 of ACM Computing Surveys, Vol. 23, No. 2, which are incorporated herein by reference.
From the compiled design, a program file such as a "bitstream", a sequence of data ("ones" and "zeros", or high and low bits) is created. The formats of two such bitstreams used in XC4000-Series FPGAs are described on pages 4-56 and 4-57 of the Xilinx 1996 Data Book entitled "The Programmable Logic Data Book" (hereinafter referred to as "the Xilinx Data Book"), available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which are incorporated herein by reference. (Xilinx, Inc., owner of the copyright, has no objection to copying these and other pages referenced herein but otherwise reserves all copyright rights whatsoever.) The generation of a bitstream file requires knowing the desired state of each programmable memory cell in the FPGA and the bit location in the bitstream corresponding to each such memory cell. Each bit in the bitstream is then set to the appropriate value for the corresponding memory cell. The generation of bitstream program files is well known in the art of configuration software for programmable ICs. For example, bitstream program files are used by many FGPA manufacturers, including Xilinx, Inc., as mentioned above. Bitstream program files are also used in the ORCA.TM. OR2C FPGAs from Lucent Technologies Inc. ("ORCA" is a trademark of Lucent Technologies, Inc.) The ORCA bitstream and the use thereof are described in pages 2-45 through 2-54 of the Lucent Technologies October 1996 Data Book entitled "Field-Programmable Gate Arrays", available from Microelectronics Group, Lucent Technologies Inc., 555 Union Boulevard, Room 30L-15P-BA, Allentown, Pa. 18103, which are incorporated herein by reference. Streams of configuration data are also used in the FLEX.TM. 8000 from Altera Corporation, as disclosed in Application Note 38 "Configuring Multiple FLEX 8000 Devices", May 1994, version 2, available from Altera Corporation, available from Altera Corporation, 2610 Orchard Parkway, San Jose, Calif. 95134-2020, which are incorporated herein by reference. ("FLEX" is a trademark of Altera Corporation.)
The bitstream is then used to configure a programmable IC. Several methods for loading bitstream data into programmable ICs are known. One such method is described by Stephen M. Trimberger in U.S. Pat. No. 5,426,379, issued Jun. 20, 1995, entitled "A Field Programmable Gate Array With Built-In Bitstream Data Expansion", which is incorporated herein by reference.
The design process is complicated and can be time-consuming. Therefore, many programmable IC vendors are now offering "macros" to their customers. These "macros" are circuits that have already been entered as either schematicor language-based descriptions. Therefore, a customer can save valuable development time by incorporating a vendor-supplied macro in a design rather than generating his or her own comprehensive circuit description. Further, a macro is tested and debugged by the vendor before it is provided to the customer, and therefore is more likely to produce a working circuit than a new circuit description entered by the customer.
One common form in which macros are provided to customers is in "libraries", typically as a set of schematic symbols and netlists referenced by these schematic symbols. Some macro libraries include high-level schematics having one or more levels of schematics below them. Xilinx, Inc., provides some macros in a form called "Relationally Placed Macros", or RPMs. RPMs are described on pages 4-71 and 4-72 of the Xilinx "Libraries Guide", published October 1995 and available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which are incorporated herein by reference. An RPM is a schematic that includes constraints defining the order and structure of the underlying circuits. The location of each element within the RPM is defined relative to each other element in the RPM, regardless of eventual placement in the overall design. For example, an RPM might contain 8 flip-flops constrained to be placed into four Configurable Logic Blocks (CLBs) in a vertical column. The column of four CLBs can then be placed anywhere in the FPGA. The schematics forming the RPM are user-editable.
Providing a macro to a customer in a user-editable format such as a language-based, schematic-based, or netlist description can have several consequences that may be considered undesirable by a vendor, such as a programmable IC vendor or a macro designer. For example, the macro can be copied, edited, and redistributed by the customer. The vendor's considerable investment in the design of the macro may therefore be lost. Similar disadvantages apply if the macro is easily reverse-engineered from the supplied description, even if the description is not readily edited in its originally provided format. A netlist, for example, can typically be reverse-engineered relatively easily.
Another disadvantage of user-editable macros is that such macros often comprise very complicated circuits, difficult to design and having tight timing requirements. If a design is changed in any way, the circuit may no longer be fully functional at the required speed. Therefore, it is not commercially feasible for a vendor to guarantee performance of the macro. Any such guarantee must carry prohibitions against modification of the design.
It is therefore desirable to have a method of generating and providing secure macros (i.e., macros that are difficult to edit or reverse-engineer) for programmable ICs.
Xilinx, Inc. did at one time have a method of generating and providing secure macros for its XC4000 family of FPGAs. These macros were called "hard macros". Hard macros are described in the "XC4000 Family Hard Macro Style Guide", published Sep. 3, 1991 and available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which is incorporated herein by reference in its entirety. A "hard macro" did not require schematics; instead, it included a schematic symbol that was used to include the macro in a customer design, and a netlist referenced by the schematic symbol and representing the macro circuitry. The netlist was encrypted and sent to customers in binary format, which made it difficult to edit or reverse-engineer the netlist.
One disadvantage of the hard macro format was that the area of the FPGA encompassed by the hard macro was totally dedicated to the contents of the macro. A customer could not place additional logic in a CLB within the area, or access any signal inside the area unless the signal had an output port as part of the defined hard macro. Further, the area of the FPGA encompassed by the hard macro had to be rectangular. If the logic fit best, or resulted in the fastest performance, in a non-rectangular area, the "extra" CLBs required to make the area rectangular were wasted. Further, hard macros did not include routing, not even the routing within the macro rectangle. The routing had to be added later when the macro was compiled along with the rest of the design. Therefore, timing of the macro logic was unpredictable.
It is desirable to have a method of generating and providing secure macros for programmable ICs that overcomes these disadvantages.